feat(slirp): slirp_crr tracing target for CRR-path investigation#82
Closed
feat(slirp): slirp_crr tracing target for CRR-path investigation#82
Conversation
Adds 4 tracing::trace! call sites under target slirp_crr that emit a
timeline of one TCP CRR cycle through voidbox:
- process_guest_frame: when a guest frame queues ≥1 outbound frame
+ epoll_waker.wake() fires.
- SYN-ACK queued in handle_tcp_syn_outbound (immediate-connect path).
- drain_to_guest: when ≥1 frame is drained to the net-poll thread.
- net_poll_thread: epoll_wait return (with raw_events / wait_us /
timeout_ms) and try_inject_rx + IRQ raise.
Filtered out by default; cost is one atomic-load per call site when
RUST_LOG=slirp_crr=trace is unset. Activate with:
RUST_LOG=warn,slirp_crr=trace target/release/voidbox-network-bench ...
Used to root-cause the voidbox-vs-pasta CRR p50 gap: 122x is dominated
by guest-side fork+exec of busybox-nc per CRR iteration (8.6ms inter-
event rhythm in the trace), not the voidbox NAT path itself (per-event
work is microsecond-scale). Keeping the instrumentation in tree so
the next investigation doesn't have to rebuild it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Four
tracing::trace!call sites under targetslirp_crrthat emit a timeline of one TCP CRR cycle through voidbox. Filtered out by default; cost is one atomic-load per call site whenRUST_LOG=slirp_crr=traceis unset.Used to root-cause the voidbox-vs-pasta CRR p50 gap (122× from PR #81's harness): the gap is dominated by guest-side
ncfork+exec per CRR iteration, not voidbox's NAT path. Trace evidence in the PR description below.What it traces
process_guest_frameexit (when ≥1 frame queued)epoll_waker.wake()firedhandle_tcp_syn_outbound(immediate-connect path)drain_to_guestexit (when ≥1 frame drained)net_poll_thread:epoll_waitreturn +try_inject_rx+ IRQ raiseActivation
RUST_LOG=warn,slirp_crr=trace target/release/voidbox-network-bench --iterations 1 \ --output /tmp/voidbox-bench.json 2> /tmp/crr-trace.logThen grep for
slirp_crrand post-process for inter-event gaps.Findings from the first run (CRR p50 ≈ 10 ms)
ACTIVE_TIMEOUTcadence innet_poll_threadis the floorprocess_guest_framealready wakes when frames are queued.ncper iterationThe trace shows the net-poll thread waiting 3.5–3.7 ms between events, in a steady rhythm of one cycle every ~8.6 ms during the CRR phase. That gap is not voidbox sleeping past a deadline — it's voidbox waiting for the next packet from the guest. Each iteration spawns a fresh
nc; busybox-nc fork+exec inside the guest dominates per-iteration cost.Cost when not activated
tracing::trace!with targetslirp_crris an atomic-load when no subscriber filters it in. Verified: the bench numbers from PR #81's harness were taken with RUST_LOG=info; identical to the pre-instrumentation run within bench noise.Test plan
cargo fmt --all -- --checkcargo clippy --workspace --all-targets --all-features -- -D warningscargo test --test network_baseline -- --test-threads=1— 18/18RUST_LOG=warn,slirp_crr=trace voidbox-network-bench --iterations 1produces parseable trace linesFollow-up (not in this PR)
A guest-side static binary that runs N TCP CRRs in a single process — eliminates the fork+exec contribution and isolates voidbox's NAT-path CRR cost so we can size the real gap to pasta. Tracked separately.